Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/textfile/faqs/lan_faq/big_lan_

Internet Message Format | 1992-12-26 | 61.6 KB

Xref: bloom-picayune.mit.edu news.answers:3537 comp.dcom.lans.misc:909
Path: bloom-picayune.mit.edu!snorkelwacker.mit.edu!hri.com!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!usc!rpi!newsserver.pixel.kodak.com!psinntp!newstand.syr.edu!spider.syr.EDU!jmwobus
From: [e-mail] (John Wobus)
Newsgroups: news.answers,bit.listserv.big-lan,comp.dcom.lans.misc
Subject: BIG-LAN/bit.listserv.big-lan FAQ
Message-ID: <[e-mail]>
Date: 16 Oct 92 17:17:31 GMT
Reply-To: [e-mail]
Followup-To: poster
Organization: Syracuse University, Syracuse, NY
Lines: 1329
Approved: [e-mail]
Originator: [e-mail]

Archive-name: LANs/big-lan-faq

BIG-LAN Frequently Asked Questions

Last Updated: October 13, 1992

Acknowledgements: A lot of people provided information for me and I freely
admit that I have not recorded the list of names.  Thanks to all.

Contents
--------
I. About BIG-LAN
II. Explanation of this Memo
III. Sources of Information on Campus Networks
  1. Must-Read Sources
  2. A Few General Sources
  3. LISTSERV Mailing Lists
  4. Internet Mailing Lists
  5. USENET/Netnews Groups
  6. Anonymous FTP-based Archive Sites
  7. LISTSERV-based Archive Sites
  8. RFCs (Internet "Request For Comments")
  9. Other Useful Online Papers
  10. Sources of Protocol Documents
  11. Useful Free Software
  12. Books
  13. Periodicals
  14. Training Courses
  15. Conferences
IV. Basic Glossary on Campus Networks
V. Frequently Asked Questions on Campus Networks
  1. What is the difference between Ethernet and IEEE 802.3?
  2. What is encapsulation?  What do I have to know about it?
  3. How do I know whether to use a router or a bridge?
  4. How do I know whether to use a bridge or a repeater?  How many
     repeaters may I put on an Ethernet?
  5. Should I use "manageable" hubs, concentrators, etc on my LAN?
  6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?  10BASE-T?
  7. What is the ideal cable to install in a new building?
  8. What is the ideal cable to install between buildings on a campus?
  9. Whose routers are recommended?
  10. Whose bridges are recommended?
  11. Whose Ethernet equipment are recommended?
  12. Whose Token Ring equipment are recommended?
  13. Whose FDDI equipment are recommended?
  14. What PC network software is recommended?
  15. What protocols should run on a campus-wide LAN?
  16. What software is recommended for managing a campus-wide LAN?
  17. What terminal server is recommended?
  18. Whose troubleshooting equipment are recommended?
  19. What security products should I buy?
  20. Should the names of devices on my campus LAN have subdomains?
  21. Should client stations use POP?  Should they use just SMTP?  Should
      I use some non-TCP/IP protocol for mail to/from client stations?
  22. Should I enable SQE/heartbeat?

I. About BIG-LAN

   BIG-LAN is a mailing list for discussion of issues in designing and
   operating Campus-Size Local Area Networks, especially complex
   ones utilizing multiple technologies and supporting multiple
   protocols.  Topics include repeaters, bridges, routers and
   gateways; how to incorporate smaller Personal-Computer type LANs
   into the campus-wide LAN; how to unify the mail systems, etc.
   This is an ideal list in which to debate the relative merits of
   bridges vs routers.

   All requests to be added to or deleted from this list, problems,
   questions, etc., should be sent to [e-mail]
   (Internet) or BIG-REQ@SUVM (Bitnet).  Those familiar with LISTSERV
   can subscribe with [e-mail] (Internet) or
   LISTSERV@SUVM (Bitnet).

   Archives are available through LISTSERV and anonymous ftp.

   Coordinator: John Wobus <[e-mail]>
                           <JMWOBUS@SUVM>

II. Explanation of this Memo

     Since BIG-LAN is not specific to any protocol family, it will
     not cover any particular protocol family in detail, e.g.  this
     is not a TCP/IP/Internet FAQ Memo.  Fortunately, there are some
     good TCP/IP FAQ Memos which are listed in the sources of
     information below.

     Suggestions, corrections, and contributions welcome.  Please
     send them to:

                [e-mail]
                [e-mail]

III. Sources of Information on Campus Networks

     This list favors "network" sources of information: available on
     the Internet and/or BITNET and other similar networks; if you
     have access to BIG-LAN then you have access to one of these
     networks; and these sources are not the kind which you can
     discover through vendors, books, bookstores, or libraries.

  1. Must-Read Sources

      These are documents that you definitely should get and read if you
      have questions about Campus Networks.

    a. Charles Spurgeon's reading list (see below under "Other Useful
        Online Papers").
    b. RFCs 1175, 1206, and 1207 (see below under "RFCs").

  2. A Few General Sources

     These are network resources & mechanisms for getting all kinds
     of information--not just on Networking; thus we can't cover them
     very thoroughly in this memo.

    a. LISTSERV - mailing list servers & file servers on BITNET, accessible
        via e-mail.  Can be reached and used from a lot of networks.
        Mail the command INFO to any LISTSERV for help.  Also have
        database commands (i.e. search commands) for archives they store.
    b. Usenet News/Netnews: distributed bulletin board with discussions
        on lots of topics.  Distributed through the Internet and through
        UUCP.
    c. Anonymous ftp: the main way to make files available on the Internet.
        ftp to a site using username "anonymous".  A password is always
        demanded--sometimes a banner tells you what to use--otherwise
        "guest" almost always works.
    d. Archie servers - network-accessible databases of where to get
        files via anonymous ftp.  Access is through telnet, rlogin,
        mail, or a special "archie" protocol.  To use via telnet,
        enter username archie.  Some servers: archie.ans.net,
        archie.sura.net, archie.mcgill.edu, archie.unl.edu.
    e. WAIS - Internet-accessible databases on different topics.
        Available via WAIS protocol (basically Z39.50).  Client
        (and server) software is collected on quake.think.com as
        well as a WAIS database of WAIS servers.
    f. ftplist.txt - collected list of anonymous ftp sites.
        Stored lots of places in anonymous ftp including syr.edu.
    g. Internet gopher - something like anonymous ftp only more advanced:
        to get started, I suggest ftping boombox.micro.umn.edu and getting
        information on gopher.  A number of sites have servers.
    h. Internet List of lists: available by anonymous ftp from
        ftp.nisc.sri.com, or through a mail-based file server
        at [e-mail].
    i. LISTSERV internal list of lists.  Available by mailing the command
        LIST GLOBAL to any LISTSERV.
    j. news.answers - newsgroup that distributes Frequently Asked
        Questions memos for lots of Netnews groups.
    k. FAQ archive available via anonymous ftp on pit-manager.mit.edu
        From the archives of news.answers, Frequently Asked Question
        memos for lots of Netnews groups.
    l. news.announce.newusers - has periodic postings about how to
        use Usenet/Netnews and also a lot about mailing lists.
    m. BITFTP.  A BITNET server that allows BITNET sites to use the
        Internet's File Transfer Protocol to send/receive files to
        ftpable Internet sites.  For more information, send mail
        to BITFTP@PUCC with HELP as the message body.
    n. Database of lists managed by [e-mail].  Use through
        LISTSERV's database interface.
    o. Maas files--Indexes & abstracts about various services available
        via Internet & BITNET including some related to campus networks.
        Available via anonymous ftp from ftp.unt.edu.
    p. [e-mail] mailing list.  A list to exchange information
        on the location of network resources.  LISTSERV-based so use
        instructions below to subscribe, etc.


  3. LISTSERV Mailing Lists

      Send a "SUBSCRIBE" command to LISTSERV@foo, e.g.
              SUBSCRIBE BIG-LAN John Doe

    a. [e-mail]/SUVM.ACS.SYR.EDU
    b. [e-mail]/SUVM.ACS.SYR.EDU
    c. [e-mail]/IDBSU.IDBSU.EDU
    d. [e-mail]
    e. [e-mail]    (Campus Wide E-mail)
    f. [e-mail]         (Campus Wide Information Systems)
    g. [e-mail]
    h. [e-mail]      (LANWatch User List)
    i. [e-mail]
    j. [e-mail]
    h. [e-mail]    (Help re networking software)

  4. Internet Mailing Lists

      Send a subscription request for list foo to foo-request@blah

    a. [e-mail]             (gives you 2 ways)
    b. [e-mail]
    c. [e-mail]          (Proteon routers)
    d. [e-mail]
    e. [e-mail]
    f. [e-mail]
    g. [e-mail]
    h. [e-mail]
    i. [e-mail]
    j. [e-mail]               (OSPF IP routing protocol)
    k. [e-mail]
    l. [e-mail]
    m. [e-mail]
    n. [e-mail]       (Packet Drivers)

  5. USENET/Netnews Groups

    a. comp.dcom.*          lans, modems, sys.cisco, telecom, ...
    b. comp.protocols.*     appletalk, tcp-ip, ibm, ppp, ...
    c. comp.sys.proteon
    d. comp.sys.novell
    e. comp.sys.mac.comm
    f. bit.listserv.big-lan  (Note: these groups give Netnews
    g. bit.listserv.novell     readers a way to read the corresponding
    h. bit.listserv.cwis-l      LISTSERV lists)
    i. bit.listserv.cw-mail
    j. bit.listserv.3com-l
    k. alt.dcom.*           catv, telecom, ...

  6. Anonymous FTP-based Archive Sites

    a. syr.edu: BIG-LAN mailing list; NOVELL mailing list; a collection of
        network-oriented papers.
    b. spot.colorado.edu: cisco mailing list & some other network stuff
    c. hsdndev.harvard.edu: (in pub/rtests/10.91) Results of Scott
        Bradner's router benchmarks.
    d. ftp.uu.net: a treasure trove of software.
    e. wuarchive.wustl.edu: a treasure trove of software.
    f. vax.ftp.com: packet drivers, some Unix software, other stuff.
    g. ftp.utexas.edu: collection of networking info & software.
    h. ftp.slc.is.novell.com: files Novell makes available.
    i. ftp.cisco.com: files Cisco makes available & some interesting
        applications.
    j. gatekeeper.dec.com: a treasure trove of software & stuff
        (the stuff that was on decwrl.dec.com).
    k. lux.levels.unisa.edu.au: files that 3Com distributes via
        Compuserve.
    l. ftp.unt.edu: Maas files and other goodies.
    m. simtel20.army.mil: a treasure trove of software, including
        packet drivers (pd1:<msdos.pktdrvr>).  Mirrored on ftp.uu.net
        and wuarchive.wustl.edu.
    n. osi.ncsl.nist.gov: online copies of GOSIP & related documents.

  7. LISTSERV-based Archive Sites

     The brave can mail the command "INFO FILES" and/or the command
     "INFO DATABASE" to the LISTSERV for instructions.

    a. [e-mail]: BIG-LAN & NOVELL mailing list archives.

  8. RFCs (Internet "Request For Comments")

     Some anonymous ftp sites for RFCs: nic.ddn.mil, ftp.nisc.sri.com,
     nis.nsf.net, nisc.jvnc.net, venera.isi.edu, wuarchive.wustl.edu.
     There are also some mail-based file servers:
     [e-mail], [e-mail], and
     [e-mail].

    a. RFC1147: FYI on a network management tool catalog: Tools for
        monitoring and debugging TCP/IP internets and interconnected devices
    b. RFC1175: FYI on where to start: A bibliography of internetworking
        information
    c. RFC1206: FYI on Questions and Answers: Answers to commonly asked
        "new Internet user" questions
    d. RFC1178: Choosing a name for your computer
    e. RFC1207: FYI on Questions and Answers: Answers to commonly asked
        "experienced Internet user" questions
    f. RFC1244: Site Security Handbook
    g. RFC1118: Hitchhiker's Guide to the Internet
    h. RFC1122 & RFC1123: Requirements for Internet Hosts
    i. RFC1208: A Glossary of Networking Terms
    j. RFC1180: A TCP/IP Tutorial
    k. RFC1173: Responsibilities of Host and Network Managers:
        A Summary of the Oral Tradition of the Internet
    l. IAB Official Protocol Standards (Currently RFC1250 but it is
        periodically updated & given a new RFC number)
    m. Assigned Numbers (Currently RFC1060 but it is periodically
        updated & given a new RFC number; Includes field-values for
        protocols in the TCP/IP family as well as some others)

  9. Other Useful Online Papers

    a. Charles Spurgeon. "Network Reading List: TCP/IP, UNIX, and
        Ethernet".  Available via anonymous ftp from ftp.utexas.edu
        in directory pub/netinfo/docs as net-read.txt and netread-ps.
        Also available via electronic-mail-based archive server.  Send
        the word "help" in the subject header or body of a message
        to [e-mail] for more information.
    b. Charles Hedrick. "Introduction to the Administration of an
        Internet-based Local Network".  Available via anonymous ftp
        from cs.rutgers.edu as runet/tcp-ip-admin.doc (also .ps).
    c. Charles Hedrick.  "Introduction to Internet Protocols."
        Available via anonymous ftp from cs.rutgers.edu as
        runet/tcp-ip-intro.doc (also .ps).
    d. Unofficial lists of codes used on 802.3 & Ethernet networks.
        Portions of the official list are not released, so various
        people compile unofficial lists.  One that is available via
        anonymous ftp is Michael Patton's pub/map/EtherNet-Codes
        on ftp.lcs.mit.edu.  See also RFC: "Assigned Numbers".
    e. Scott Jenkins: "Frequently Asked Questions for NOVELL@SUVM
        Mailing List."  Available via anonymous ftp from
        info.umd.edu in the info/Computers/Novell/Information directory.
    f. Brendan Kehoe: "Zen and the Art of the Internet: A Beginner's
        Guide to the Internet."  Available via anonymous ftp from
        ftp.cs.widener.edu in the pub/zen directory.

  10. Sources of Protocol Documents

    a. Ethernet V2   DEC-Direct; 1-800-344-4825; DEC Part Number AA-K759B-TK.
    b. IEEE 802      (802.3, Token Ring, 10BASE-T, etc) IEEE; 1-800-678-IEEE.
    c. TCP/IP        RFCs.  See RFCs (above).
    d. Appletalk     APDA; 1-800-282-APDA.  Now a book in the "Inside" series.
    e. OSI           Omnicom Inc.; 1-800-666-4266.
    f. DECNet        DEC.
    g. SNA           IBM.
    h. Novell(IPX)   Built on XNS; rest is designed by Novell.
    i. FDDI          ANSI; 1-212-642-4900.
                      Also Global Engineering Documents; 1-800-854-7179.
                      2805 McGaw Avenue; PO Box 19539; Irvine, CA 92714;
                      1-714-261-1455.
    j. CCITT         United Nations book shop in New York
    k. GOSIP         NTIS Sales Dept; [phone]; Document FIPS 146-1;
                      See also Anonymous FTP-based Archive Sites
    l. XNS           Xerox.

  11. Useful Free Software
     (see also RFC1147; listed above)

    a. CUTCP           (TCP/IP client for PCs) sun.soe.clarkson.edu,
                        omnigate.clarkson.edu
    b. NCSA Telnet     (Telnet clients for PCs & Macs) ftp.nsca.uiuc.edu
    c. Eudora          (POP3 Client for Macs) ux1.cso.uiuc.edu
    d. POPmail         (POP3 Client for PCs & Macs) boombox.micro.umn.edu
    e. PCROUTE         (Makes IP router out of PC) accuvax.nwu.edu
    f. PCBRIDGE        (Makes bridge out of PC) accuvax.nwu.edu
    g. Packet Drivers  (Drivers for various PC LAN cards) simtel20.army.mil
    h. WinQVT          (IP clients for Windows) ftp.cica.indiana.edu
    i. ka9q            (TCP/IP for PCs and Macs) ucsd.edu
    j. PC/IP           (TCP/IP client for MS-DOS) husc6.harvard.edu
    k. charon          (Pegasus/smtp gateway) omnigate.clarkson.edu
    l. CAP             (AppleTalk for Unix systems) rutgers.edu, munnari.oz.au,
                        gatekeeper.dec.com
    m. Popper          (POP3 server for Unix systems) ftp.cc.berkeley.edu
    n. Trumpet         (PC Newsreader) simtel20.army.mil
    o. bootpd          (Bootp Daemon for Unix) lancaster.andrew.cmu.edu
    p. NUPOP           (POP3 daemon for MS-DOS) ftp.acns.nwu.edu
    q. PC netwatching program [I don't know name or site]
    r. iupop3          (POP3 server for VMS) mythos.ucs.indiana.edu

  12. Books

    The following books were mentioned by responders to the 12/91
    BIG-LAN Reader Survey as good books for administrators of Campus-sized
    LANs:

    a. Douglas Comer.  Internetworking with TCP/IP.
    b. Marshall Rose.  The Simple Book.
    c. Caroline Arms.  Campus Networking Strategies.  Digital Press.
    d. DEC Telecomm. & Network Buyer's Guide.
    f. Marshall Rose.  The Open Book.
    g. Carl Malamud.  Analyzing Novell Networks.
    h. Andrew Tanenbaum.  Computer Networks.
    i. Martin A. W. Nemzow.  Keeping The Link (McGraw-Hill).
    j. William Stallings.  Local Networks: an Introduction.
    k. John McCann.  NetWare Supervisor's Guide.
    l. William Stallings.   Handbook of Communications Standards. (?)
    m. Nemeth, Snyder & Seebass.  Unix System Administration Handbook.

    Other interesting looking books:

    n. Mark A. Miller.  Troubleshooting Internetworks.

  13. Periodicals

    The following periodicals were mentioned by responders to the 12/91
    BIG-LAN Reader Survey as good periodicals for administrators of Campus-
    sized LANs:

    a. LAN Times
    b. Communications Week
    c. Network Computing
    d. ConneXions
    e. Data Communications
    f. Network World
    g. LAN Magazine
    h. Info World
    i. SunExpert
    j. Telecommunications
    k. Computerworld
    l. DataCommunicationInternational
    m. Datamation
    n. Digital Review
    o. LAN Technology
    p. Lightwave
    q. MacUser
    r. MacWeek
    s. MacWorld
    t. Networking Management
    u. PC Week

  14. Training Courses

    The following providers of tutorials were mentioned by responders to
    the 12/91 BIG-LAN Reader Survey:

    a. Interop
    b. ACM SIGComm
    c. Learning Tree
    d. Novell
    e. PSI
    f. Usenix

  15. Conferences

    The following conferences were mentioned by responders to the 12/91
    BIG-LAN Reader Survey as good conferences for administrators of Campus-
    sized LANs:

    a. Interop
    b. Usenix
    c. ComNet
    d. NetWorld
    e. ACM SIGComm
    f. DECUS
    g. IETF


IV. Basic Glossary on Campus Networks

   Another glossary is RFC1208.  See "Online Papers" above.

     ANSI "American National Standards Institute" - A definer of
       standards of all kinds, including FDDI.

     Appletalk - A protocol family developed by Apple Computer to
       implement LANs serving Macintoshes.

     ATM "Asynchronous Transfer Mode" - a method for switching little
       fixed-size packets (cells) around.  Like T1 and DS3, digitized
       voice was a major consideration in its design, but it can be
       used for data.  It is designed around fixed speeds too, roughly
       150MBS and 600MBS.  The fixed cell size is 53 bytes.  Though ATM
       is really designed for voice and WANs, there are schemes to use
       it in LANs.  ATM is a big buzzword these days but it is still
       very new.

     AUI "Attachment Unit Interface" - the Ethernet/IEEE 802.3 term
       for the interface between a MAU and a station.  A special kind
       of cable known as an "AUI Cable" can attach a MAU to a station
       at a distance (up to 50 meters).

     BNC Connector "Bayonet Neill-Concelman connector" - a type of
       connector used for attaching coax cable to electronic equipment
       which can be attached or detached quicker than connectors that
       screw.  ThinWire Ethernet (IEEE 802.3 10BASE2) uses BNC connectors.

     Bridge - A network "relay" which reads, buffers, and sends
       data to relay it from one data link to another, but makes
       the two data links appear as one to levels higher than the
       data link layer.

     CDDI "Copper Data Distribution Interface" - essentially a way to
       use electrical communications cables in an FDDI network.  Several
       companies have worked out ways to do this but ANSI has yet to
       standardize one.  I think CDDI was coined by Crescendo corporation
       for their scheme, but it may well be adopted by ANSI as the name.
       So far there are schemes that work on Coax, on STP and UTP, but
       the front runners look like they will be able to run on UTP for
       about 100 meters.

     CMIP "Common Management Information Protocol" - An OSI protocol
       for management of network equipment.  Not widely implmented.
       See SNMP.

     CMOT "CMIP over TCP/IP" - A protocol consisting of CMIP running
       under TCP/IP.  An alternative to SNMP.

     Coaxial Cable - any of a number of kinds of electrical
       communications cable designed so one conductor is in the
       center and the second conductor forms a ring around it.
       Depending upon who you talk to, someone might have a specific
       kind of coaxial cable in mind.  Some well known kinds are
       various Cable TV cables, cables used by IBM 327x terminals
       and ARCnet, and cables used by Ethernet & IEEE 802.3.

     DECnet - Trade name of Digital Equipment Corporation for some
       of their networking products.  It is a kind of network
       built out of Digital Equipment Corporations own networking
       protocols (with some standard protocols also used).

     Dialup Modem - Modem used over ordinary dial-up telephone lines
       as opposed to private or leased lines.

     Ethernet - LAN data-link protocol developed by a consortium
       of vendors; later standardized as IEEE 802.3 with a few
       modifications.  For many applications, users have not adopted
       all the IEEE 802.3 differences.  Ethernet/802.3 now can be
       run on two types of coaxial cable as well as multi-mode
       fiber and unshielded twisted-pair.  "Raw" rate of data
       transmission is 10 megabits/second.

     FDDI "Fiber Data Distribution Interface" - LAN data-link protocol.
       Designed to run on multi-mode fiber.  "Raw" rate of data
       transmission is 100 megabits/second.  Developed by the American
       National Standards Institute.

     FDDI-2 - Same speed, same fiber, same basic protocol as FDDI.
       FDDI-2 adds a layer which allows you to allocate fixed bandwith
       to applications of your choice, making it more like broadband.
       FDDI-2 is still rather new.

     Fiber - optical fiber: a very long, narrow, flexible piece of glass.
       Used for high-speed communications.

     FOIRL "Fiber Optic Inter-Repeater Link" - a standard for running
       IEEE 802.3 over fiber.  It was originally designed to link two
       repeaters, and only supports two attachments.  Many users use it
       to attach a station to a repeater.  See 10BASE-F.

     FTP - Protocol in the "TCP/IP" family for copying files from
       one computer to another.  Stands for "File Transfer Protocol".

     Gateway - A type of "network relay" that attaches two networks
       to build a larger network.  Modern "narrow" usage is that it
       is one that translates an entire stack of protocols, e.g.,
       translates TCP/IP-style mail to ISO-style mail.  Older usage
       used it for other types of relays--in particular, in the "TCP/IP"
       world, it has been used to refer to what many now insist is
       a "router".

     GOSIP "Government Open Systems Interconnect Profile" - A subset of
       OSI standards specific to US Government procurements, designed
       to maximize interoperability in areas where plain OSI standards
       are ambiguous or allow options.  Theoretically, required of all
       US Government networking procurements since mid-1990.

     Heartbeat - In Ethernet (Version 2), a test of the collision
       functionality of the transciever.  The term "Heartbeat" is often
       (wrongly) used interchangeably with "SQE" which is a similar
       function of IEEE 802.3.  See Question on SQE/Heartbeat below.

     IPX - Novell's protocol used by Netware.  Utilizes part of XNS.
       A router with "IPX routing" purports to interconnect LANs so
       that Novell Netware clients & servers can talk through the router.

     MAU "Media Adaptor Unit" - an IEEE 802.3 or Ethernet device which
       attaches a station to the cable.  Popularly called a "transceiver".
       Can be attached by cable to the station or built into the
       station.

     MIB "Management Information Base" - the set of parameters an SNMP
       management station can query or set in an SNMP agent (e.g. router).
       Standard, minimal MIBs have been defined (MIB I, MIB II), and vendors
       often have custom entries.  In theory, any SNMP manager can talk
       to any SNMP agent with a properly defined MIB.

     Multimode fiber - A type of fiber mostly used for shorter, e.g. campus
       distances.  It can carry 100 megabits/second for typical campus
       distances, the actual maximum speed (given the right electronics)
       depending upon the actual distance.  It is easier to connect to than
       Single Mode Fiber, but its limit on speed x distance is lower.

     NFS "Network File System" - an IP-based protocol originally developed
       by Sun Microsystems which provides file services.

     OSI "Open System Interconnect" - A standard put forth by the ISO for
       communication between computer equipment and networks.

     OSI Reference Model - A model put forth by the ISO for communication
       between computer equipment and networks, which maps out 7 protocol
       layers.

            Top layer:  layer number 7:   application layer
                        layer number 6:   presentation layer
                        layer number 5:   session layer
                        layer number 4:   transport layer
                        layer number 3:   network layer
                        layer number 2:   data-link layer (e.g. IEEE 802.x)
         Bottom layer:  layer number 1:   physical layer (wire & electricity)

       This model explains what each layer does.  The model is often
       used to explain anyones protocols (not just OSI) to the point
       where many people seem to believe that true data-communications
       requires these 7 layers.

     POP "Post Office Protocol" - A TCP/IP-based protocol designed to allow
       client-stations (e.g. micros) to read mail from a server.  There
       are three versions under the name "POP": POP, POP2, and POP3.
       Latter versions are NOT compatible with earlier versions.

     Protocol - The "rules" by which two network elements trade information
       in order to communicate.  Must include rules about a lot of mundane
       detail as well as rules about how to recover from a lot of unusual
       communication problems.  Thus they can be quite complicated.

     Relay - One terminology uses the term "relay" as a device that
       interconnects LANs, different kinds of relays being repeaters,
       bridges, routers, and gateways.

     Repeater - In the "Ethernet" world, a "relay" that regenerates and
       cleans up signals, but does no buffering of data packets.
       It can extend an Ethernet by strengthening signals, but timing
       limitations on Ethernets still limit their size.

     RFC "Request For Comments" - The name is a real red herring when
       it comes to Internet RFCs.  Some really are "Requests For Comments"
       but all Internet protocol documents are stamped with an RFC number
       that they never shake, so the acronym RFC generally refers to
       documents that describe protocols in the TCP/IP family.

     RG numbers (E.g. RG62; sometimes there are qualifiers, e.g. RG 58
       A/U) a shorthand designation for military cable.  RG58 & RG62
       designate two different types of cable used by the military.
       Some data-communications equipment was designed to work with
       a particular military standard, e.g.  IBM 3270-type terminals
       use RG62.  In other cases, people use an RG-numbered cable
       that is close to what they need: for example Thinwire
       Ethernet & IEEE 802.3 10BASE2 define the type of cable they
       need and people sometimes substitute flavors of RG58, which
       are "close".  One can't recommend this practice because you
       can get yourself in trouble.  I think "RG" originally stood
       for "Radio Guide", presumably reflecting the fact that the
       series of cables was designed to handle radio frequencies.  The
       IEEE 802.3 10BASE2 specifications define two RG numbered cables
       (RG58 A/U and RG58 C/U) as meeting the cable requirements for
       thin Ethernet.  However, cable vendors may list a range of
       cables under these same RG numbers, and some of the cables
       listed may not meet the 802.3 specs.  You need to check the
       cable specifications closely, and beware of relying on the RG
       number alone when ordering network cables.

     Router - A network "relay" that uses a protocol beyond the
       data-link protocol to route traffic between LANs and other
       network links.

     Routing Protocol - a protocol sent between routers by which
       routers exchange information own how to route to various parts
       of the network.  The TCP/IP family of protocols has a bunch,
       such as RIP, EGP, BGP, OSPF, and dual IS-IS.

     Shielded Twisted Pair - a type of twisted-pair cable with a
       metallic shield around the twisted conductors.  The shield
       reduces the noise from the cable and reduces the effects of
       noise on the communications in the cable, but changes the
       electrical characteristics of the cable so some equipment
       optimized to non-shielded cable runs worse on shielded cable.

     Single Mode fiber - a type of fiber optic cable used for longer
       distances and higher speeds, e.g.  for long-distance telephone
       lines.  See also "Multimode Fiber".

     SMTP "Simple Mail Transfer Protocol" - the protocol in the
       TCP/IP family used to transfer electronic mail between
       computers.  It is not oriented towards a client/server system so
       other protocols (see "POP") are often used in that context.
       However, servers will use SMTP if they need to transfer a
       message to another server.

     SNMP "Simple Network Management Protocol" - Originally developed
       to manage IP based network equipment like routers and bridges,
       now extended to wiring hubs, workstations, toasters, jukeboxes,
       etc.  SNMP for IPX and AppleTalk under development.  Widely
       implemented.  See CMIP.

     SQE Test "Signal Quality Error Test" - an IEEE 802.3 function
       that tests the transceiver.  The term "SQE" is often (wrongly)
       used interchangeably with "Heartbeat" which is a similar
       function of Ethernet Version 2.  See Question on SQE/Heartbeat
       below.

     TCP/IP "Transmission Control Protocol/Internet Protocol" -
       literally, two protocols developed for the Defense Data Network
       to allow their ARPANET to attach to other networks relatively
       transparently.  The name also designates the entire family of
       protocols built out of IP and TCP.  The Internet is based upon
       TCP/IP.

     TELNET - a protocol in the TCP/IP family that is used for
       "remote login".  The name is also often used as the name of the
       client program that utilizes the TELNET protocol.

     Terminal Server - a network device that allows a number of
       terminals to attach to a LAN, and do remote logins across the
       LAN.

     TN3270 - A variant of the TELNET program that allows one to
       attach to IBM mainframes and use the mainframe as if you had a
       3270 or similar terminal.

     Token Ring - People often mean 802.5 when they say "Token Ring"
       (see below).  In the more general sense of the word, a type of
       LAN that has stations wired in a ring, where each station
       constantly passes a special message (a "token") on to the next.
       Whoever has the token can send a message.

     Tunnelling - An important concept in the design of many kinds of
       networks: taking some protocol-family's ability to move packets
       from user to user, or to open virtual-circuits between users,
       and use this as if it were a data-link protocol to run another
       protocol family's upper layers (or even the same protocol
       family's upper layers).  Examples: running TCP/IP over Appletalk
       instead of something like Ethernet; running Appletalk over
       DECnet instead of something like Localtalk or Ethernet.

     Twisted Pair - The type of wire used by the phone company to wire
       telephones -- at least over distances like between your house
       and the central office.  It has two conductors, which are twisted.
       The twists are important: they give it electrical characteristics
       which allow some kinds of communications otherwise not possible.
       Ordinary telephone cables are not shielded (see "Shielded twisted
       Pair").

     T1 - A phone-company standard for running 24 digitized voice circuits
       through one 1.5megabit/second digital channel.  Since phone companies
       run lots of T1, and will run T1 between customer sites, the
       standard is often used for data communications, either to provide
       24 low-speed circuits, or to provide 1 high-speed circuit, or to
       be divided other ways.

     UTP (Unshielded Twisted-Pair) -  See "Twisted-Pair" and "Shielded
       Twisted-Pair".

     X.400, X.500 - OSI protocols for mail and directory services.

     10BASE-T - A variant of IEEE 802.3 which allows stations to be attached
       via twisted-pair cable.

     10BASE-F - A variant of IEEE 802.  3 under development which
       allows stations to be attached via multimode fiber.  It will
       offer a variety of methods of using fiber in an IEEE 802.3
       network that go beyond what is currently offered in FOIRL.  The
       current 10BASE-F draft is likely to be confirmed.  draft is
       likely to be confirmed.  Sections of the draft include "Fiber
       Optic Medium and Common Elements of Medium Attachment Units and
       Star, Type 10BASE-F (Section 15)", "Fiber Optic Passive Star and
       Medium Attachment Unit, Type 10BASE-FP (Section 16)", "Fiber
       Optic Medium Attachment Unit, Type 10BASE-FB (Section 17)", and
       "Fiber Optic Medium Attachment Unit, Type 10BASE-FL (Section
       18)".

     802 - The set of IEEE standards for the definition of LAN protocols.
       A story goes that a long time ago, IEEE and ANSI decided that
       IEEE would get the slow protocols and ANSI would get the fast
       ones, thus IEEE defined the 802 protocols and ANSI defined FDDI.
       Presumably IEEE saw limited application for FDDI at the time.
       Also, the IEEE standards-making committees associated with these
       standards.

     802.1 - The IEEE 802 standard for Network Management and Network
       Bridging of IEEE 802 networks.

     802.2 - An IEEE standard for the portion of LAN data-link protocols
       that is the same for all flavors of IEEE LAN protocols, e.g.
       802.3 and 802.5.  Sometimes not used.

     802.3 - An IEEE standard for LANs--their "improved" version of Ethernet.
       See Ethernet.

     802.4 - An IEEE standard for LANs: Token Bus networks.  Basically,
       standardizes MAP, a protocol that operates a Token Bus protocol on
       broadband.

     802.5 - An IEEE standard for Token-Ring-based LANs.  See Token Ring.

     802.6 - An IEEE standard for Metropolitan Area Networks.  Also known
       as DQDB.

     802.7 - IEEE 802 technical advisory group on Broadband.

     802.8 - IEEE 802 technical advisory group on FDDI & fiber optics.

     802.9 - IEEE 802 group on integrated data & voice networks.

     802.11 - Proposed IEEE 802 group for wireless Ethernet.


V. Frequently Asked Questions on Campus Networks

     It is hard to answer typical BIG-LAN questions in advance for
     two reasons.  Answers are often long and they are often
     controversial.  To provide some sort of objective information
     relevant to the controversies, a survey of BIG-LAN readers was
     taken on answers to various questions, so this memo could offer
     a sampling of opinions.  Note that the opinions below are
     extracted from the 41 responses received for the survey.  We
     can't say these 41 responses represent a fair sampling of campus
     LAN administrators, but they do show some of the answers that
     you would get if you posed some of these questions to the
     BIG-LAN readership.

  1. What is the difference between Ethernet and IEEE 802.3?

     Ethernet ran through an evolution starting with some
     experimenting at Xerox, and ending with a standard
     published by Xerox, DEC, and Intel, which they offered to
     the world (with minimal royalties) as a standard technology
     for building LANs.  The Institute of Electrical &
     Electronic Engineers took this as a proposed standard, and
     rewrote the protocol description making some clarifications
     and a few changes.  Some of the changes have been
     universally adopted, and others have not.  After the first
     go round of IEEE standard defining, Ethernet version 2 was
     introduced which brought it more into line with standards.
     The basic differences are:

         - Heartbeat vs SQE (see below)
         - Which pin in the MAU & AUI connectors carry the ground
            conductor
         - Packet Length Field vs Type Field

     The latter issue is the one in which IEEE 802.3 has not
     displaced Ethernet.  Ethernet had a 16-bit field which
     defined the type of packet (examples: IP, XNS, Appletalk).
     The IEEE committee decided to use that field to specify the
     length of the packet, and have the data-portion of the
     packet define itself through the next higher level of
     protocol (e.g., IEEE 802.2).  However, the sets of possible
     values for that field used by the two different protocols
     are completely separate, and both protocols are designed to
     deliberately ignore packets with fields outside their own
     sets of values.  Thus Ethernet and IEEE 802.3 packets can
     coexist on the same cable, though a computer which expects
     to get packets belonging to just one of the protocols won't
     notice any packets sent according to the rules of the other
     (the expression used is "they pass by each other like ships
     in the night").

     These days, LANs use both.  There is a way to send TCP/IP
     packets via 802.3, but when 802.3 was introduced, there
     were already so many systems using the Ethernet rules that
     the use of Ethernet-style packets for TCP/IP has persisted
     now for years.

  2. What is encapsulation?  What do I have to know about it?

     One encapsulation issue on LANs is whether IEEE 802.3
     packets are used or Ethernet packets are used to
     encapsulate your traffic on your IEEE 802.3/Ethernet LAN.
     See previous question for more explanation.  Most TCP/IP
     systems use Ethernet, any that uses IEEE 802.3 by default
     might surprise you by not interoperating with the rest of
     your TCP/IP network.

     A second encapsulation issue on IEEE 802.3/Ethernet
     networks is whether your Novell (IPX) packets use Novell's
     default encapsulation or whether they use Ethernet-style
     encapsulation.  Novell, at least for a long time, had the
     distinction of using IEEE 802.3 as if it were the only
     protocol on the network, not following the rules for
     avoiding other protocols running under IEEE 802.3 rules.
     They offered a utility called ECONFIG that changed Netware
     to use Ethernet rules, and use them properly, so Novell IPX
     packets could utilize the same LAN as other protocols.  In
     no case would the Novell traffic bother Ethernet traffic--
     only any other IEEE 802.3 traffic if ECONFIG wasn't used.
     In any case, a single Ethernet segment, or bridged
     segments, had to have all Novell servers and clients
     configured the same, in order to interoperate.

     A third encapsulation issue stems from Berkeley Unix 4.2,
     from which many versions of Unix and many TCP/IP
     implementations have been modeled.  It used, by default,
     its own encapsulation rules (i.e., manner of putting IP
     packets within Ethernet packets) which is termed "Trailer
     Encapsulation".  When an Ethernet had some computers using
     Trailer Encapsulation and some not, TCP/IP connections
     would often work, but hang when large data transfers were
     taking place.  The next version of Berkeley Unix, version
     4.3, remedied this by avoiding Trailer Encapsulation except
     when it was guaranteed to work correctly.

     A fourth encapsulation issue is "tunnelling", which
     consists of one of the layers in the protocol stack
     mimicking another layer to provide a way of running a
     different set of upper layers than would otherwise be
     possible.  This is rather widely used and seldom explained
     to beginners.  It is perhaps best explained with an actual
     example:

[Here put an example, perhaps Appletalk over IP]

[Include "encapsulated bridging" as a second example]

  3. How do I know whether to use a router or a bridge?

     (Note that the answer to this question is oriented to
     Ethernet-based LANs).  Few administrators of networks doubt
     that a network can be large enough to require routers nor
     that there are situations where a bridge is an effective
     solution.  However, there is controversy as to where to
     draw the line.  Campus-sized networks involving distances
     of up to a mile and possibly thousands of stations, can be,
     and have been built solely out of one or the other.  The
     BIG-LAN Survey of 12/91 showed the following opinion among
     respondents:

       Survey question: "When you build a campus network, do you
       tend to use bridges as opposed to routers?"

       Answers: 9 said yes; 26 said no; 2 said "brouters"
       (combination bridge/routers) would be the best solution.

     Some clear tradeoffs: routers generally have to be set up
     no matter what whereas bridges can be plug-and-play on a
     network without too much total traffic; bridges generally
     have a higher speed-to-cost ratio and the low-end bridge is
     less expensive than the low-end router; routers handle huge
     networks with links of different speeds better.

  4. How do I know whether to use a bridge or a repeater?  How many
     repeaters may I put on an Ethernet?

     You cannot keep plugging more repeaters and add more cables to
     an Ethernet indiscriminately and expect it to work.  With too
     large a networks, the protocol which keeps the number
     of collisions down (known as CSMA/CD) fails to do that.  The
     protocol documents supply rules-of-thumb which, if followed,
     prevent this from occurring.  If you break them, you may be risking
     large performance degradations.

     The latest version of the rules-of-thumb (which have been updated
     over time as new features like 10BASE-T have been added to the
     protocol) are in the IEEE 802.3 document describing 10BASE-T,
     specifically IEEE Std 802.ei-1990 in the section called "System
     Considerations for Multisegment 10 Mb/s Baseband Networks"
     (When 10BASE-F is released later, this section will be updated again).
     The rules refer to the piece of the LAN that is between repeaters
     as a segment and refer to 4 kinds: 10BASE5 (i.e. "classic" Ethernet)
     and 10BASE2 (i.e., ThinWire Ethernet) both classified as "Coax"
     segments and FOIRL (fiber inter-repeater links) and 10BASE-T, both
     classified as "Link" segments, and both of which have the property
     that you can attach things only to their ends.  The basic repeater
     rule is that between any two stations on the LAN, there may be
     at most 4 repeaters and three coax segments.  In addition, there
     are length restrictions on the segments which are designed to
     keep CSMA/CD working properly:

        10BASE5         500 meters
        10BASE2         185 meters
        FOIRL           500 meters (1000 meters in some cases)
         10BASE-T        100 meters (or more)

     FOIRL links can be 1000 meters if you have at most 3 repeaters
     between stations instead of 4.  10BASE-T links can be longer
     if the cable will support it: CSMA/CD is not the limiting factor
     on 10BASE-T.  For the purposes of this discussion, bridges, routers,
     and gateways are "stations" since the CSMA/CD protocol does not
     pass through them.  Thus if you discover these rules prevent
     you from putting a repeater in the network where you need one, then
     you can put a bridge there instead, or perhaps split the LAN
     somewhere else using a bridge.

  5. Should I use "manageable" hubs, concentrators, etc on my LAN?

     This is a controversial question also.  Vendors have
     attempted to make hubs and concentrators that require
     little training & manpower to manage & troubleshoot, and
     they will attempt to convince you that they have succeeded.
     You pay a premium for "manageability".  Those who remain
     skeptical wonder how much the management features are ever
     used: for example, management allows you to turn on & off
     ports from an operator's console; how often do you need to
     do such a thing?  Also, some of the benefits attributed to
     management packages are simply due to good record keeping,
     something which the administrator must find the manpower to
     accomplish with a management package or without one
     (presumably with a simple dbms, which can often be tailored
     more to the administrators needs).

  6. Which LAN technology should I use?  Arcnet?  FDDI?  Token Ring?  10BASE-T?

     A controversial question.  Some questions & answers from
     the 12/91 BIG-LAN Reader Survey:

       "When you install a LAN, which "Technology" (e.g.
       Ethernet, Token Ring) do you prefer?"

       37 responders said Ethernet; 2 said "pick one and stick
       with it"; 1 said token ring.

       "If you have experience with two or more LAN technologies,
       which have you found works better?"

       Answers received:
          "Ethernet works best"                        7
          "Ethernet works better than Token Ring"      4
          "Depends on application"                     1
          "Ethernet works better than ARCnet"          1
          "Ethernet works better than Broadband"       1
          "Ethernet best, Localtalk 2nd, ARCnet 3rd"   1
          "Ethernet works better than PhoneNet"        1
          "Token Ring works best"                      1

  7. What is the ideal cable to install in a new building?

     Distribution runs, i.e., phone closet to room: Best
     possible thing to do is to leave usable pathways for future
     expansion.  Whatever you do, install at least 2 pair and
     probably 4 pair of data grade unshielded twisted pair.  It
     will always have uses.  Install something else too if you
     are tied to a particular vendor.  Multimode fiber might
     become popular in the future but that is a gamble.

     Riser runs, i.e., phone closet to phone closet: it is
     imperative to leave usable pathways for future expansion.
     For Ethernet, ThinWire is a usable riser cable, multimode
     fiber is possible too.

  8. What is the ideal cable to install between buildings on a campus?

     Trunks, i.e., cables into the building: pathways for future
     expansion very valuable.  Multimode fiber is useful, run 24
     fibers if you can.  Use cable with some single mode too.
     Run several times what you need initially and leave a lot
     of the unused fiber unterminated for the time being.  Cable
     pulling & termination are much more costly than the cable
     itself.

  9. Whose routers are recommended?

     Question & answer from the 12/91 BIG-LAN Reader Survey:

       "Name some router vendors whose routers you have used and
       recommend:"

       Cisco got 30 mentions; Wellfleet 4; PCRoute 2; Proteon 2;
       Apple 1; DEC 1; Network Systems 1; Shiva 1; Vitalink 1;
       3COM 1.

  10. Whose bridges are recommended?

     Question & answer from the 12/91 BIG-LAN Reader Survey:

       "Name some bridge vendors whose routers you have used and
       recommend:"

       DEC got 6 mentions; Retix 5; BICC 3; Cabletron 3; 3COM 3;
       Cisco 2; PCBridge 2; Vitalink 2; ACC 1; Clearpoint 1;
       Datability 1; Develcon 1; Dowty Scanet 1; HP 1; IBM (Token
       Ring) 1; Network Application Technology 1; PCBRoute 1;
       Wellfleet 1.

  11. Whose Ethernet equipment are recommended?

     Question & answer from the 12/91 BIG-LAN Reader Survey:

       "Name some Ethernet concentrator/transceiver/repeater
       vendors whose Ethernet equipment you have used and
       recommend:"

       Cabletron got 20 mentions; BICC 8; DEC 8; HP 4; Synoptics
       4; David 3; Lantronix 3; Gandalf 2; Lannet 2; Pirelli Focom
       2; Acton 2; Allied Telesys 1; AMP 1; Asante 1; Chipcom 1;
       Dowty Scanet 1; Dupont Electroptic 1; EAZY 1; Fibermux 1;
       Hirschmann 1; IMC Network Corporation 1; NetCor
       Transceivers 1; Sension 1; 3COM 1.

  12. Whose Token Ring equipment are recommended?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some Token Ring equipment vendors whose Token Ring
       equipment you have used and recommend:"

       IBM was mentioned by 6 responders; FiberMux 1; Madge 1;
       Synoptics 1.

  13. Whose FDDI equipment are recommended?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some FDDI equipment vendors whose FDDI equipment you
       have used and recommend:"

       Cisco was mentioned by 6 responders; DEC 2; Tymeplex 2;
       ALCATEL 2; AT&T 1; Synernetics 1; Tekelec 1.

  14. What PC network software is recommended?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some PC network software vendors whose PC network
       software you have used or recommend:"

       Novell was mentioned by 19 responders; FTP Software 14; Sun
       8; DEC 3; Apple 2; Farallon 2; InterCon 2; 3COM 2; Beame
       and Whiteside 1; Hummingbird Communications 1; IBM 1;
       Microsoft 1; NCSA 1; Neon Software 1; Network Application
       Technology 1; Sitka 1.

  15. What protocols should run on a campus-wide LAN?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some protocols that you use to interconnect your
       campus that you would recommend:"

       TCP/IP was mentioned by 39 responders; Appletalk 9; DECNET
       9; IPX 9; LAT 2; Coloured Book 2; G.703 2; ISO CONS 2;
       X.25/HDLC 1; XNS 1.

  16. What software is recommended for managing a campus-wide LAN?

     Queries and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some network management system that you use for the
       management of a campus LAN, that you recommend:"

       PSI SNMP was mentioned by 4 responders; Cabletron Remote
       LanView 2; Cisco NetCentral 2; Proteon Overview 2; SNMP 2;
       "A good drawing program" 1; DEC EMA 1; Map 1; NEMISYS from
       SEEL 1; SunNet Manager 1; TRW NMS 1.

       "Name other software that you use for the management of a
       campus LAN that you recommend:"

       FTP LanWatch was mentioned by 3 responders; EtherPeek 2;
       ping 2; AG Group Net Watchman for Appletalk 1; Apple
       Interpoll 1; Clarkson Packet Driver Utilities 1; DEC LAN
       Traffic Monitor 1; Domain Name System 1; inetrover 1; LAN
       Patrol 1; Neon Software Netminder Localtalk 1; Neon
       Software Netminder Ethernet 1; Network Application
       Technology EtherMeter 1; Shiva Net Manager 1; SNMP-Gawk (A
       SNMP-capable Gawk) 1; traceroute 1; Unix 1; Watchdog 1.

  17. What terminal server is recommended?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name vendors of terminal servers that you use and
       recommend:"

       Cisco was mentioned by 13 responders; DEC 5; Xyplex 4;
       Datability 2; Xylogics 2; 3COM 2; Emulex 1; Lantronix 1;
       Netcomm 1; Spider 1; TRW 1.

  18. Whose troubleshooting equipment are recommended?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some vendors of network troubleshooting equipment
       that you use and would recommend:"

       Network General was mentioned by 8 responders; HP 4;
       Tektronix 4; Cabletron 3; Novell 3; Spider 3; AG Group 2;
       Wandel and Goltermann 2; FOTEC 1; Neon Software 1.

  19. What security products should I buy?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "Name some security products that you use to maintain
       security on your campus LAN that you recommend:"

       The answers reflected the lack of obvious products to
       choose from.  Responses included "Athena Kerberos",
       "Encryption in Net3270", "Extended TACACS', "Host
       security", "Physical security", "Router access control
       lists", "SecurID", "Virus Scan", and "Windows Workstation".

  20. Should the names of devices on my campus LAN have subdomains?

       Example of name without subdomain: bigvax.sequoia.edu;
       example with subdomain: bigvax.acs.sequoia.edu.  It is
       possible to run networks of thousands of computers without
       the bother of subdomains, but they have some advantages.

     Queries and answers from the 12/91 BIG-LAN Reader Survey:

       "For Internet names of nodes on a campus network that
       supports TCP/IP, do you prefer the use of subdomains?"

       27 responders said yes, 5 said no, 2 said it depends.

       "If you have worked on a campus that utilizes subdomains
       and one that does not, which does your experience tell you
       is the better way to administer names in a campus network?"

       5 responders said the LAN with subdomains worked better; 2
       said the LAN without subdomains worked better.  One
       responder claimed that a good rule of thumb is that a LAN
       with more than 4000 stations works better with subdomains.

  21. Should client stations use POP?  Should they use just
      SMTP?  Should I use some non-TCP/IP protocol for mail
      to/from client stations?

     Query and answers from the 12/91 BIG-LAN Reader Survey:

       "For client station's mail, which do you prefer: SMTP;
       TCP/IP-based client-server protocols (e.g.  POP, POP2,
       etc); other LAN protocols?"

       10 responders preferred TCP/IP-based client-server
       protocols (e.g.  POP, IMAP, PCMAIL); 7 preferred SMTP; 4
       said "use all three"; 3 preferred users signing onto a host
       system; 2 preferred other LAN protocols; 1 said "SMTP and
       TCP/IP-based client-server protocols"; 1 said "SMTP and
       X.400".


  22. Should I enable SQE/heartbeat?

     This is a very brief discussion of SQE and CPT (both commonly
     referred to as "heartbeat") for IEEE 802.3 and Ethernet.  For
     really gory details, see the appropriate documents, IEEE
     standard 802.3, ISO standard 8802-3, and the DIX Ethernet V2
     Standard.  (The first 2 references are, in theory, identical.)

     First, SQE and CPT are not quite the same thing.  CPT is a part
     of DIX Ethernet Version 2 and is simply a test of collision
     detection functionality in the MAU (that's the correct name for
     a transceiver, Media Access Unit).  It is ALWAYS present in
     Ethernet V2 MAUs and can't ever be disabled (without modifying
     the hardware).  It is required for correct operation of ALL
     Ethernet V2 equipment.

     SQE, on the other hand, is part of the 802.3 specification and
     performs basic MAU tests and "reports" to the controller if all
     is well.  The "report" is in the form of a pulse nearly
     identical to the V2 CPT pulse, but with slightly differing
     timing specifications.  It should be switchable, as 802.3
     requires SQE for all terminal equipment, but prohibits it for
     repeaters.

     SQE and Heartbeat both appear as a signal in the collision lines
     from the MAU to the controller after every write.  This is why
     MAUs with SQE enables and with displays show a collision every
     time they show a write.  THIS IS NORMAL!

     Quick digression: What is a collision?  Of course, we all know
     that a collision is when two controllers start to transmit at
     the same time (more of less) and that when this happens both
     will stop and wait for a random interval and then retransmit if
     carrier is not present.  This function is critical to proper
     network operation.  A MAU which can't detect a collision can
     mess up a network badly.  This makes it critical to be able to
     quickly isolate "broken" MAUs.  If you don't understand this,
     read any of the old papers on multiple access nets, especially
     the old Aloha Net.  Collisions are a normal part of Ethernets.
     There is nothing "wrong" with having collisions.  The name seems
     to make people think that they are somehow bad.  If you start to
     feel that way, say to yourself 20 times before going to be
     tonight: "Collisions are my friend."

     Having said all of that, there is one type of collision that is
     NOT your friend.  The "Late Collision".  This is a collision
     which is generated more than 60 bytes into a packet.  Since the
     is "impossible", it indicates that something is seriously wrong.
     Too long a cable, a bad MAU, or some other hardware problem.  IF
     you are getting late collisions, you are also likely corrupting
     packets without knowing it because collisions are not being
     properly detected.

     In practice, MAUs hardly ever fail.  BUT IF ONE DOES, YOU MAY
     HAVE A BIG PROBLEM!

     While SQE indicates a bit more than heartbeat did and is
     slightly different in both timing and electrical
     characteristics, they are essentially the same from the
     perspective of most terminal equipment and you can replace an
     Ethernet V2 MAU with an 802.3 MAU with SQE enabled most of the
     time.  (A notable exception is an Ethernet repeater which really
     requires an Ethernet V2 MAU.  There may be others.) You can even
     replace an 802.3 MAU with an Ethernet V2 one most of the time.
     In fact, there are "fixes" for some Ethernet V2 MAUs to disable
     heartbeat and make them into something like an 802.3 MAU with
     SQE disabled.  This also seems to work almost all the time.

     Anyone still with me?  OK.

     RULE FOR SQE.  Always turn it on except for repeaters.  There
     should be no exceptions to this rule, but there are.  Some
     manufacturers can't seem to read standards (or just don't care).
     As a result there are some terminal devices that get upset when
     they see SQE.  I have been told that this is true of the cisco
     AGS, but not the IGS; not that there is any documentation on
     this.  Several email exchanges with cisco folks have not
     clarified this.

     There is one BIG special case, the Etherrnet fan-out box, most
     commonly a DEC DELNI.  This box has only one MAU, so it repeats
     the CPT (it's a V2 device) that it sees from the MAU on the
     "master" port.  If the master port is disabled, CPT is generated
     internally to keep things happy.

     But, what if you plug a repeater into a DELNI?  You can disable
     CPT by using an 802.3 MAU with SQE disabled.  or, if you don't
     use the master port, turn it on and plug an Ethernet loopback
     connector into the master port.  In either case, CPT is disabled
     to ALL PORTS!  No way around this.

     DELNIs produce other oddities.  They reduce the maximum segment
     length on segments connected to the master port to 300 meters
     and shorten the maximum length of the AUI cable used between the
     system and the DELNI by 5 meters.  (And don't forget to include
     the length of the cable between the interface and the connector
     on the rear of the cabinet.) Because of these and other
     oddities, I try to avoid DELNIs.  And I NEVER EVER plug a
     repeater of any type into one.

     Other companies make 802.3 equivalents to the DELNI on which SQE
     may be switched on each port.  While this fixes one problem, the
     timing concerns of fan-out boxes remains.  Buyer beware!
     Neither 802.3 nor Ethernet V2 standards cover fan-out boxes in
     any way, so there is no way to really claim that they meet
     standards (or don't).

     We've now covered the basics.  So what happens when a MAU fails?
     In theory, every time it transmits a packet, an error is logged.
     This happens on some equipment.  But most software I've dealt
     with simply ignores the error flag and does nothing.  So SQE
     makes absolutely no difference to these systems.  THIS IS BAD
     SOFTWARE DESIGN.

     Once in a while a MAU does fail.  If it is on some device that
     does not log SQE failures or has a MAU with SQE turned off, you
     don't know what is happening.  If you are on 10BASE-T, it can be
     isolated to a hub pretty quickly, but on coax you are reduced to
     segmenting the cable (physically disconnecting it) until you
     have isolated the problem.  This is NOT fun and makes the
     network manager very unpopular since the network tends to be
     down for a LONG time.  It took about 4 hours last time I had
     this problem and could have taken longer.

     What's a network manager supposed to do?  Complain vigorously to
     vendors of equipment that don't adhere to the standard.
     Complain equally to vendors of software that doesn't bother to
     log the failures.  SNMP is no good if the agents don't have any
     information to send out.

End of Memo: BIG-LAN Frequently Asked Questions